You'll have to do a fair amount of manual setup work to try any of this out.  The hardest part will be setting up the web server. 

Somewhere in the webserver's document root you'll need a set of directories like this: 

repo_root/  (this name can be changed, but the subdirectories cannot)
	catalogs/
	manifests/
	pkgs/
	pkgsinfo/
	

When populated, they'll look something like:

repo_root/
	catalogs/
		<populated by the makecatalogs tool>
		
	manifests/
		artlab_leopard
		greg_neagle
		production_leopard
		testing_leopard
		
	pkgs/
		Firefox3.0.3.dmg
		Firefox3.1b1.dmg
		TextWrangler2.3.pkg.dmg
		ServerAdminToold1055.dmg
		adobe/
			AdobePhotoshopCS3.dmg
			AdobePhotoshopCS4.dmg
		disney/
			DAPasswordChanger.dmg
			DisneyAnimationSetupAssistant4.6.dmg
		microsoft/
			Office2008.dmg
			Office2008SP1.dmg
			Office2008v12.1.7update.dmg
		other_vendor/
			someflatpackage.pkg
			
	pkgsinfo/
		adobe/
			AdobePhotoshopCS3
			AdobePhotoshopCS4
		apple/
			ServerAdminTools-10.5.5
		apps/
			Firefox-3.0.3
			Firefox-3.1b1
		disney/
			DAPasswordChanger
			DASetupAssistant
		microsoft/
			Office2008-12.0.0
			Office2008-12.1.0
			Office2008-12.1.7
		other/
			someflatpackage
			

To serve up the manifests, you have two choices. The easiest to get started is to just create a repo_root/manifests directory and put your manifests there, then set the ManifestURL in /Library/Preferences/ManagedInstalls.plist to http:/yourwebserver/repo_root/manifests/
and set the ClientIdentifier in /Library/Preferences/ManagedInstalls.plist to the name of a manifest 
so the final url is 
http:/yourwebserver/repo_root/manifests/name_of_manifest
The other choice is implementing the CGI in the code/server folder in this distribution.  Ask if you want more info on that.


Bootstrapping:
Put some installer items (flat packages or dmgs) in repo_root/pkgs/
Create pkginfo files.
Copy the manifest example (manifest.plist) to repo_root/catalogs/.  Rename if you'd like.

You're done with the webserver.
On a client:

Edit ManagedInstalls.plist (from the Preferences folder in this distribution):
Change the ManagedInstallDir key to point to your desired directory. My eventual intention is /Library/Managed Installs, but for testing I've been using /Users/Shared/Managed Installs
Change the ManifestURL in /Library/Preferences/ManagedInstalls.plist to http:/yourwebserver/repo_root/manifests/
Change the ClientIdentifier to the name of the actual catalog file on the webserver (perhaps simply client_manifest.plist for now...)
Change the SoftwareRepoURL to the url to repo_root.
Copy this file to /Library/Preferences/.

Now, from the code/client directory:

As root, run managedsoftwareupdate.  You should get a copy of the client_manifest.plist in your {ManagedInstallDir}/manifests/. It should get more info on the items in the manifest by consulting the catalog(s) and decide if they need to be installed.  If so, the installer items will be copied to ManagedInstallDir/Cache/
The process logs its activities at ManagedInstallDir/Logs/ManagedSoftwareUpdate.log

Finally: as root, run managedsoftwareupdate --installonly, and the items in {ManagedInstallDir}/Cache should be installed.  Logs from this process go in {ManagedInstallDir}/Logs/ManagedSoftwareUpdate.log


More notes:

In the code/client directory:
Tool: managedsoftwareupdate:
This is the main client tool. It functions in a similar manner to Apple's softwareupdate command-line tool.
Client asks for a main manifest.  It's retrieved.  Main manifest contains some metadata and a list of managed installs. On the client, it's named client_manifest.plist, though on the server it may have any name.
managedsoftwareupdate requests a manifest via one of three values:
1) if you pass --id=arbitrarystring at the command line, it uses 'arbitrarystring' as the request:
http://webserver/repo/manifests/arbitrarystring
2) If no --id option is passed, it looks for a ClientIdentifier value in /Library/Preferences/ManagedInstalls.plist and uses that.
3) If no ClientIdentifier is available, it uses the fully-qualified hostname of the machine:
http://webserver/repo/manifests/hostname.mycompany.com
Note that if the ManifestURL takes the form of a CGI invocation (http://webserver/cgi-bin/getmanifest?), the final URLs look like
http://webserver/cgi-bin/getmanifest?arbitrarystring
The CGI approach will open the possibility for pattern matching and more logic in the client-to-catalog mapping...

Next, the client asks for more detail on each managed install.
As we get more detail on each managed install, we may discover some dependancies, so we request more info on these as well.
We then check the items to see if they are already installed.
For items that are not installed, or have an older version, we download installer items and put them in a staging folder.
(any items previously staged that have no corresponding catalog item are removed from the staging folder - this covers the case where an item is erroneously added to a manifest and then removed before it is actually installed)
Using the dependency info and the catalog items, we build a list of items to be installed and their order. (InstallInfo.plist)

Unless the --auto option is passed, after checking for and downloading updates, managedsoftwareupdate will quit. You'll need to run it a second time with --installonly to get it to install the updates.  This is a safety measure to make it less likely you'll accidently install something that requires a restart underneath a logged-in user.

Tool: Managed Software Update.app
This app will be used to notify the user that there are updates to be installed, and ask them to log out to have them installed, or notify them that they will be installed at next logout.



Tool: makepkginfo
Creates a managed install package info file given an Installer item:
a .pkg, a .mpkg, or a .dmg containing a .pkg or .mpkg
at the root of the mounted disk image.

You may also pass additional items that are installed by the package. These
are added to the 'installs' key of the catalog item plist and are used when 
processing the catalog to check if the package needs to be installed or 
reinstalled.
The generated plist is printed to STDOUT.

Usage: makepkginfo /path/to/package_or_dmg [-f /path/to/item/it/installs ...]


Tool: makecatalogs /path/to/repo
This tool scans the /path/to/repo/pkgsinfo directory and builds catalogs from the pkginfo files.

